NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/lang/c-part2/14424

Text File | 1996-08-05 | 3.9 KB | 93 lines

Newsgroups: comp.lang.c
Path: mvb.saic.com!eskimo!scs
From: [e-mail] (Steve Summit)
Subject: Re: 16bit vs. 32bit
X-Nntp-Posting-Host: eskimo.com
Message-ID: <[e-mail]>
Sender: [e-mail] (News User Id)
Organization: schmorganization
References: <[e-mail]> <[e-mail]> <4kk16j$[e-mail]>
Date: Sun, 14 Apr 1996 19:12:23 GMT

In article <4kk16j$[e-mail]>, [e-mail]
(gregg jennings) writes:
> In article <[e-mail]> [e-mail] (Steve Summit) writes:
>> [I and others had written:]
>>>>> ...If you find yourself needing to
>>>>> know the sizes of things in bits, someone screwed up.
>>>>
>>>> Yeah. Maybe it was the guy who wrote the program in a 32-bit Unix
>>>> machine seven years back that stores data in binary format to a file
>>>> you now have to read in a 16-bit DOS machine?
>>
>> Indeed.
>>
>>> And, how did that programmer "screw up" ?
>>
>> By choosing a binary data file format, and condemning later
>> programmers to use machine-dependent code if they wished to read
>> it efficiently.
>
> You are right but...
>
> In data compression, for example, one just has to know the size of
> things in bits!

You are right, but I believe it is possible to write portable
compression programs and to design portable compressed formats.
(Certainly, my statement that "If you find yourself needing to
know the sizes of things in bits, someone screwed up" was an
oversimplification.)

> Yes using a non-arbitrary data file format make sense, especially
> for common applications such as word processors (microsoft take
> note please!), but there may always be some situations where
> portability of data formats is just not required.
>
> Choosing a data format as you indicate implies pre-cognition:
>    1. You knew that a higher-bit system was going to appear in
>       the future (we all think that now, but many years ago?).
>    2. You knew that the data was not going to be limited to one
>       machine/implementation...

Look at it this way.  I advocate using portable (preferably
text-based) data file formats whenever possible.  You may
disagree, but let's think about person #3, who wrote some data
with a 32-bit Unix machine seven years back, and person #4, who
now has to read it with a 16-bit DOS machine.  Which of us does
person #4 wish that person #3 had listened to?  (For that matter,
which of us do you wish Microsoft had listened to?)

> Also, like moving up in bit size, whose to say that ASCII will be
> portable forever?  (Although in all probability it just might.)

ASCII text is so ubiquitous that it's reasonable to assume that
there will always be easy ways either to read it directly, or
to convert it transparently (that is, without knowing anything
about its structure) into a format that can be read.

> How about writing something that is called a data conversion program?

I've written those, yup.  The more of them I have to write and
maintain, the bigger a nuisance it is.  It's an especial nuisance
to have to write single-purpose ones, for converting one
particular needlessly-specific format into another.

> And just how is Unix data converted to DOS?  9" tape?  Floppies?
> Serial/network connection?  All require a data conversion program
> of some type (either an application/tool or some transfer protocol).

In most cases, it's reasonable to treat any of these media
as streams of bytes (either text or binary), so writing to
or reading from them can be done with general-purpose tools,
independent of the structure of the data.  (There are of course
a few things to worry about.  You often have to specify a record
size with magnetic media, and different media and different
operating systems of course use different end-of-line
representations for text files.  If you handle end-of-line
translations appropriately in the general-purpose transfer
tools, though, individual applications don't need to care.)

                    Steve Summit
                    [e-mail]